Repository navigation
fix(compiler): convert absolute length units to pixels - #492
YevheniiKotyrlo wants to merge 8 commits into
Conversation
css-values-4 fixes in, cm, mm, Q, pt and pc against the inch (1in = 96px), so each has an exact pixel value. parseLength warned and dropped all six, so a declaration, a variable and a media query holding one set nothing on native.
Device evidence — before / afterUNFIXED — Only the control is 96 pixels wide. Every other bar spans the row, because a width in an absolute unit other than px is dropped. FIXED — Every bar is as wide as the control: an inch is 96 pixels, and centimetres, millimetres, quarter-millimetres, points and picas convert through it.
Android 16 emulator (API 36, GLES on the host GPU), 1140×2400 @ 480dpi, both frames from one run. |
…rms, shadows and font sizes
… container queries
Browser readings — the expected valuesWhat Chromium 153, Firefox 155 and WebKit 26.6 compute for each case (
Each engine clamps an infinite length to its own largest one, so the infinite rows show the inch spelling reading as the px one; the test pins the value the compiler gives the px spelling. |
…s, set the media window
This branch has not been deployed
1 participant
Problem
in,cm,mm,Q,ptandpcare absolute lengths with fixed pixel values (css-values-4).parseLengthwarns and drops all six, so on native a declaration holding one sets nothing -width: 1in,border-top-width: 3pt,margin: 1in 1pc- and neither does a variable that resolves at runtime or a media query such as(min-width: 4in).Solution
parseLengthconverts the six units to pixels through a table beside it and hands the result to itspxbranch, so an infinite or overflowing absolute length clamps ascalc(infinity * 1px)does. Declarations, shorthands, transforms, shadows, font sizes, variables, runtimecalc(), media and container queries and@propertyinitial values all read their lengths throughparseLength, so all of them convert, with or withoutinlineRem; lightningcss already folds acalc()mixing them withpx.Tests
src/__tests__/native/absolute-units.test.tsxrenders each unit as a declaration and through a variable withinlineVariables: false, withinlineRem: false, in media queries either side of a 750px window and a container query either side of 4in, in a shorthand, a transform, a shadow, a font size, a runtimecalc()and an@propertyinitial value, in upper case and negative, and ascalc(infinity * 1in)beside itspxspelling. All but the container narrower than 4in fail onmain. A finite case expects css-values-4's ratio, rounded as the compiler rounds every length, and an infinite one the value itspxspelling compiles to; Chromium, Firefox and WebKit compute the same for every finite case but the sub-pixel10mmand4Q, which each engine snaps to its layout unit, and read each infinite one as itspxspelling (readings).Verification
On Ubuntu with the workflow's steps - build, lint, typecheck,
yarn test,node --test node/__tests__/*.mjs, both library builds, the web export, the unstaged-changes checks and commitlint - everything passes merged with #500, which fixes the vendor Tailwind cases that flake onmain; without it, those cases are the only failures.The iOS dev build passes on macOS 27.0.1 with Xcode 27.0, where CI pins 26.6.
With this change
:root { font-size: 12pt }sets the rootemto 16, wheremainwarned and dropped it, while compile-timeremstill reads a:rootfont size only inpxand stays at 14.Unchanged, and older than this change: an absolute length set from JavaScript through
vars()reaches React Native as the string it was given, as docs/css-variable-inputs.md has lengths set in pixels; an infiniterem,em,vworvhlength skips thepxclamp; a runtimecalc()dropsinfinity; thepxbranch, which the six units now share, keeps a NaNcalc()and ignores the property's range; and aresolutionmedia feature readsdpiat 160 adppx.A search of the issues and pull requests for
absolute,pt,inch,unitandlength unitsfinds #458, which also changesparseLengthand merges cleanly with this.Device evidence, before and after: #492 (comment)